fix(imap): handle korean Windows encoding ks_c_5601-1987/ks_c_5601-1989 - #12654

🏁 Script executed:

#!/bin/bash
printf '%s\n' '--- applicable repository guidance ---'
find /tmp/coderabbit-repo-knowledge/nextcloud-mail-16433369 -maxdepth 2 -type f -name '*.md' -print
printf '%s\n' '--- changed hunk ---'
git diff -- lib/IMAP/Charset/Converter.php
printf '%s\n' '--- file outline and relevant source ---'
ast-grep outline lib/IMAP/Charset/Converter.php
sed -n '1,180p' lib/IMAP/Charset/Converter.php
printf '%s\n' '--- direct references ---'
rg -n 'mbEncodings|mb_encoding_aliases|mb_list_encodings|iconv|convert' lib tests 2>/dev/null | head -160

Repository: nextcloud/mail

Length of output: 15971

🌐 Web query:

PHP mb_list_encodings mb_encoding_aliases CP949 UHC alias behavior exact documentation

💡 Result:

In PHP, UHC (Unified Hangul Code) is the formally recognized encoding name used by the mbstring extension [1][2]. It serves as the primary identifier, and CP949 is explicitly documented as an alias of UHC [1][2]. Behavior and Technical Details: 1. mb_list_encodings: When you call mb_list_encodings, the output will include UHC in the list of supported encodings, but it generally will not list CP949 as a separate, distinct entry [3][4]. 2. mb_encoding_aliases: If you pass 'UHC' to the mb_encoding_aliases('UHC') function, it will return an array that includes 'CP949' among its aliases [5][6]. 3. Normalization: Because mbstring treats them as the same underlying character set, you can use 'CP949' as an input parameter in functions like mb_convert_encoding or mb_detect_encoding because the library internally maps it to UHC [1][2]. In summary, UHC is the "canonical" name within PHP's mbstring implementation, while CP949 is treated as an alias [1][2]. They are functionally interchangeable in PHP functions that accept encoding names [1][2].

Citations:

• 1: https://www.php.net/manual/en/mbstring.supported-encodings.php
• 2: https://www.php.net/mbstring.supported-encodings
• 3: https://www.php.net/manual/en/function.mb-list-encodings.php
• 4: https://www.php.net/mb_list_encodings
• 5: https://www.php.net/manual/en/function.mb-encoding-aliases.php
• 6: https://www.php.net/mb_encoding_aliases

🏁 Script executed:

#!/bin/bash
printf '%s\n' '--- PHP version and mbstring requirements ---'
rg -n '"php"|mbstring|platform' composer.json composer.lock lib tests 2>/dev/null | head -100
printf '%s\n' '--- charset converter tests ---'
sed -n '1,175p' tests/Unit/IMAP/Charset/ConverterTest.php
printf '%s\n' '--- repository-wide review and test conventions ---'
cat /tmp/coderabbit-repo-knowledge/nextcloud-mail-16433369/conventions/repo-wide.md
cat /tmp/coderabbit-repo-knowledge/nextcloud-mail-16433369/conventions/tests-unit.md

Repository: nextcloud/mail

Length of output: 14730

🌐 Web query:

PHP iconv encoding names platform dependent CP949 Windows-949 libiconv glibc documentation

💡 Result:

The availability and naming of character encodings in PHP's iconv extension are heavily dependent on the underlying system's iconv implementation [1][2]. PHP acts as an interface to the iconv library provided by the host operating system, which is typically glibc on Linux/Unix systems or GNU libiconv on Windows [1][3][4]. Because there is no single standardized naming convention for character encodings across these different libraries, encoding names such as CP949 and Windows-949 can behave inconsistently depending on the platform [1][5]. Key points regarding these encodings and platform dependencies: 1. Platform Dependence: PHP's iconv extension does not define its own encoding list. Instead, it relies on the library present on the system (e.g., glibc or libiconv) [1][2]. These libraries often have different sets of supported names, aliases, and internal mappings for specific character sets [6][5]. 2. CP949 vs. Windows-949: CP949 is widely recognized as the Microsoft Windows code page for Korean (Unified Hangul Code) [7][8][9]. While GNU libiconv explicitly supports CP949 [10][11][12], glibc's support and its recognition of various aliases may differ [6][5]. Users often encounter discrepancies where an encoding name accepted by libiconv on Windows causes an error or behaves differently when used with the glibc-based iconv on Linux [1][4]. 3. Recommended Practice: Because PHP's iconv implementation is system-dependent, applications requiring cross-platform consistency are generally advised to use the mbstring extension where possible, as it provides more consistent encoding support across different environments [13]. If iconv must be used, developers should be aware that the specific list of supported encoding names is determined by the underlying library and can be verified via the phpinfo function, which reports the active ICONV_IMPL [3]. For troubleshooting specific encoding issues, checking the installed iconv implementation and version in your environment is the recommended first step [3][2].

Citations:

• 1: https://www.php.net/manual/en/function.iconv.php
• 2: https://www.php.net/iconv
• 3: https://github.com/php/php-src/blob/fe52e5b6/ext/iconv/iconv.c
• 4: GitHub pull request 9149 in php/php-src (link omitted to avoid creating a cross-reference)
• 5: https://www.sourceware.org/glibc/manual/2.44/html_node/Generic-Conversion-Interface.html
• 6: https://sourceware.org/glibc/manual/2.41/html_node/glibc-iconv-Implementation.html
• 7: https://github.com/php/php-src/blob/fe52e5b6/win32/cp_enc_map_gen.c
• 8: https://learn.microsoft.com/en-us/windows/win32/Intl/code-page-identifiers
• 9: https://docs.oracle.com/cd/F16635_01/html/E73433/iconv-ko-7.html
• 10: https://fossies.org/dox/libiconv-1.19/localcharset_8h_source.html
• 11: https://fossies.org/dox/libiconv-1.19/cp949_8h_source.html
• 12: http://svn.code.sf.net/p/pure-data/svn/vendor/libiconv/1.13/lib/cp949.h
• 13: https://www.php.net/manual/en/mbstring.supported-encodings.php